NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/9009

Internet Message Format | 1996-08-05 | 5.9 KB

Path: keats.ugrad.cs.ubc.ca!not-for-mail
From: [e-mail] (Kazimir Kylheku)
Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++
Subject: About time this stupid "knocks the crap" subject was dropped!
Date: 7 Mar 1996 09:36:32 -0800
Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <4hmmhi$[e-mail]>
NNTP-Posting-Host: keats.ugrad.cs.ubc.ca

In article <4hmmhi$[e-mail]>,
Chip Richards <[e-mail]> wrote:
 >In article <[e-mail]>, Kazimir Kylheku wrote:
 >
 >   Computing g(x) when f(x) is intended falls under my definition of
 >   crap. It's a programming error that can have all kinds of consequences to
 >   the rest of the program whose detection is beyond the semantic analysis of
 >   any compiler.
 >
 >You've been milking this one bug for almost two weeks now.  Get over it, man!
 >Do you really do so little programming that one bug has occupied your
 >attention for this long?  Haven't you found any others yet?  Wow, get busy!

It is not one bug, it is one important _kind_ of bug. I have another example:
and this was probably the longest I have spent chasing a _single_ bug (though
in the chase, I uncovered others, no doubt). This was in a completely unrelated
project of a personal nature. I anticipate that Mr. Dewar (insert appropriate
title in place of Mr.) might immediately point a finger and utter ``Academic
fooling around! Not real work!''.

Last January I developed a MC68010 emulator for testing portions of a little
embedded OS before placing it on the ``iron''. To do the dipatching of
emulation routines from machine-language opcodes, I used a large look-up table.
Not wanting to moronically punch this table in by hand, I wrote a utility which
would take a special description file and generate the table for me. The
description file consisted of symbolic names paired with regular expressions
for typographically matching bit patterns. E.g. the bit pattern ^0110...1  will
match an opcode with an 0110 in the highest nibble, followed by three arbitrary
bits, followed by 1. Normal UNIX-style regex syntax.

Now, I eventually got the thing close to done in about two or three weeks, and
was testing it on tougher and tougher problems. I started running C programs
doing floating point calculations (implemented with GNU assembly floating
routines). I discovered that division was not working correctly.

I spent about three or four days (more like nights) chasing through the code,
looking for the thing that was incorrect. Due to this intense search, I
uncovered quite a few bugs, but not the one that I was looking for.

Eventually, when I had fixed every bug I could find by testing and code
inspection, I turned to the regular expression file in frustration. I
painstakingly verified the bit patterns against the Motorola specs, and bingo:
There was the bug.

I fixed the bit pattern, regenerated the table, recompiled, ran the division,
and there was the correct hex for the IEEE double-precision result.

No environment on God's green earth could have pointed the way to a faulty text
file that has nothing to do with the language I'm working in. Yet it's the kind
of obnoxious bug that can really waste my time. Now, that _could_ have
something to do with the availability of debugging tools for dealing with those
_other_ kinds of bugs... many of which are standard with Ada. (See, I'm not too
thick to see that!)

 >(Kazimir, in all seriousness, I bear you no ill will.  You are clearly bright,
 >fairly well informed, and are doubtless an asset to the programming community
  ^^^^^^^^^^^^^^^^^^^^

Though not well informed enough about Ada. I have clearly been playing the role
of a skeptic. I have a hard time accepting some off-the-wall claims. What good
are they to _anyone_?

 >at large, and will become moreso in the future.  But as you are finding out,
 >you can't cling so firmly to your opinions without attracting the attention of
 >people who want to loosen your hold on them just a bit! <grin>  An open mind
 >is your best defense.

I have an open mind: I'm very enthusiastic about Ada, and of course I believe
that it has all kinds of advantages to make it easier to write reliable
programs. Duh, you would have to be a blockead to not see it. But let's not be
overzealous with this language advocacy thing. I get e-mail from people that
for some reason thing that I'm slamming Ada because in reading a Usenet
posting, they see what they want to see (and I'm not sure whether I'm
altogether free of guilt in this regard, myself.) It's clear that Ada is a
great achievement, and apparently it is even something that inspires religious
devotion in programmers. That can only be an indicator of something good, IMHO.

 >I look forward to hearing about your upcoming experience with Ada--I hope it
 >proves a positive and enlightening one.  Also, I sure hope it's Ada95.
 >
 >And I'd take *ten* Kazimir Kylheku rants in place of *one* post from CJ3!)

Is that so? ;)

Don't encourage me. I really don't want to rant anymore in this thread; it's
much more interesting reading and responding to posts in comp.lang.c. Since I
joined, I have seriously upgraded my knowledge of C. I was surprised at how
much I _didn't_ know, despite using it for years. Yet, with access to the right
documents and motivation (brought about by being roasted regularly), I quickly
brought myself up to par. The neat thing is that it radically changed the way I
approach coding.

I hope I can lay my hands on the Ada ISO documents. Getting a hold of a library
copy of the 83 will probably be easier; ISO documents are expensive and hence
libraries are accordintly somewhat selective in their purchase orders. It's not
likely that I can easily find the 1995 standard.

Are there cheaper, more secular ;), publications which carry much of the body
of the Ada standards?
--